BEST PRACTICES

When Not To Use DI, IoC, and IoC Containers in .NET C#

Know when DIs aren’t the right solution, and the better design to use instead in .NET C#

Photo by Olav Ahrens Røtne on Unsplash

Throughout my years of working as a Software Engineer, I came across many occasions where I couldn’t understand the code I am looking at.

First, I thought that this is originating from a lack of knowledge from my side or my skills are not sharp enough and this was always pushing me to learn more and more.

However, after years and years of learning and implementing, I was surprised that from time to time I am still facing the same problem. How come even after 12+ years of being a Software Engineer, I am still having the same exact problem?!

Someone might answer this question that may be the code you are looking at is actually too bad and that’s why it would be so hard for anyone to understand, maybe even to the one who wrote it.

Unfortunately, no. Believe me, I hoped that this is the answer but this is not the case I am talking about. The code I am referring to is actually, by today’s standards, is perfect.

Then what?!!

Subscribe to Ahmed's Newsletter?

The Finding

When I looked closely into it, and I invested some quiet time doing this, I found one of the most important findings in my life as a Software Engineer.

Dependency Injection (DI), Inversion of Control (IoC), and IoC Containers are our friends, but like everything in life, if you abuse using them, you would get what you don’t ever wish for.

Before DI and IoC Containers, it was a hell to manage dependencies between different modules/classes and that’s why we were more careful and cautious about defining these dependencies. We used to think twice or even more about each module/class dependency before starting the implementation.